Netcode
Netcode is a blanket term for anything that somehow relates to networking in online games; netcode is a term most commonly used by gamers when discussing synchronization issues between clients and servers. The actual elements of a game engine that can cause so-called "netcode issues" include, among other things, latency, lag compensation or the lack thereof skill, simulation errors, and network issues between the client and server that are completely out of the game's hands.1 Netcode as a term tends to be used only in the gaming community, as it is not recognized as an actual computer science term.23 Contents * 1Potential causes of netcode issues ** 1.1Transport layer protocol and communication code * 2See also * 3References Potential causes of netcode issuesedit Latency is an unavoidable fact of online games, caused by not only network latency, which is largely out of a game's control, but also latency inherent in the way game simulations are run. There are several lag compensation methods used to disguise, reduce, or cope with latency, however their feasibility varies by application. A single update of a game simulation is known as a tick. The rate at which the simulation is run on a server is referred often to as the server's tickrate; this is essentially the server equivalent of a client's frame rate, absent any rendering system.4 Tickrate is limited by the length of time it takes to run the simulation, and is often intentionally limited further to reduce instability introduced by a fluctuating tickrate, and to reduce CPU and data transmission costs. A lower tickrate increases latency in the synchronization of the game simulation between the server and clients.5 Tickrate for games like first-person shooters can vary from 60 ticks per seconds for games like Quake or Counter-Strike: Global Offensive in competitive mode to 30 ticks per seconds for games like Battlefield 4 and Titanfall.[citation needed] A lower tickrate also naturally reduces the precision of the simulation,4which itself might cause problems if taken too far, or if the client and server simulations are running at significantly different rates. Games may limit the number of times per second that updates are sent to a particular client, and/or are sent about particular objects in the game's world. Because of limitations in the amount of bandwidth available, and the CPU time that's taken by network communication, some games prioritize certain critical communication while limiting the frequency and priority of less important information.46 As with the tickrate, this effectively increases the synchronization latency. Game engines may also reduce the precision of some values sent over the network to help with bandwidth use;6 this lack of precision may in some instances be noticeable. Various simulation synchronization errors between machines can also fall under the "netcode issues" blanket. These may include bugs which cause the simulation to proceed differently on one machine than on another, or which cause some things to not be communicated when the user perceives that they ought to be.1 Traditionally, real-time strategygames have used lock-step peer-to-peer networking models where it is assumed the simulation will run exactly the same on all clients; if, however, one client falls out of step for any reason, the desynchronization may compound and be unrecoverable.7 Transport layer protocol and communication codeedit See also: User Datagram Protocol § Comparison of UDP and TCP A game's choice of transport layer protocol can also affect perceived networking issues. Should the game use TCP, networking will have a high overhead cost and increased latency. Should it use UDP, the game engine may need to implement its own networking code to handle error conditions and other things that are handled by TCP;8 this increases the engine's complexity and might itself lead to issues.